Nowadays, businesses, governments, and large organizations generally are very dependent on their database systems. If the database system fails, the organization may not be able to operate. Because organizations depend so heavily on their database systems, the database systems must be reliable. One way in which reliability is achieved in database system is careful design to reduce hardware and software failures; another is redundancy of hardware and data so that hardware and software failures do not result in loss of data or of service; still another is recoverability, so that when a failure does occur, the database can be restarted without loss of data.
A technique that is commonly used to achieve recoverability is logging, e.g., whenever the database system performs a transaction, it logs the results of the operations making up the transaction in a file. The result of the logging operation is a transaction log that records operations belonging to a stream of transactions performed by the database system. When a failure occurs, the transactions in the stream that were performed up to the point of the failure can be recovered by redoing the operations specified in the log file. For this reason, such transaction logs are often termed “redo logs.”
The mining of redo logs can be utilized in a variety of ways. For instance, a mined redo log can be utilized for replication, auditing, asynchronous event deliveries, asynchronous change data capture, and database restoration. With respect to database restoration, to limit the amount of a redo log that must be read to redo changes, redo logs utilize checkpoints. The checkpoints are recorded outside the redo logs and each checkpoint corresponds to a specific position in the redo log. A checkpoint represents a point in the transaction stream and provides access to data that permits a redo log to be read beginning at the checkpoint that extends the redo log containing the checkpoint. From the checkpoint on, the contents of the extending redo log are exactly equivalent to what the contents of the original redo log would have been following the checkpoint. Thus, to restore a database system from the redo log after a failure, one need not begin the restoration at the beginning of the redo log, but may instead begin at the first checkpoint preceding the failure and make an extending redo log by restoring the checkpoint's data and making the extending redo log from the checkpoint.
A simple way of making a checkpoint is to save data at the checkpoint which represents the current state of all transactions that are active, e.g., uncommitted, when the checkpoint is made. In a system that handles a large number of transactions, making such a checkpoint is expensive both as regards to the time required to make the checkpoint and as regards to the checkpoint's size. Over time, checkpoint management becomes more difficult as the checkpoints grow in number and consume an increasing amount of memory. Conventionally, an approach to counteract the memory requirements of the increasing number of checkpoints is to manually remove certain checkpoints from memory. However, manual removal is time consuming, prone to human error, and may lead to removal of useful information that may negatively affect database system restoration.